Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LED Device Features, Fixes and Refactoring #855

Merged

Conversation

Lord-Grey
Copy link
Collaborator

@Lord-Grey Lord-Grey commented Jun 29, 2020

Summary

Features, Fixes and Refactoring around LED Devices

Added

New Devices

  • Yeelight support incl. device discovery and setup-wizard
  • WLED as own device and pre-configuration

Additional device related capabilities

  • discover, getProperties, identify, store/restore state and power-on/off
    available for Philips-Hue, Nanoleaf, Yeelight, partially for Rs232 / USB (Hid)
  • New device capabilities are accessible via JSON-API
  • New REST-API wrapper class in support of network devices, e.g. Philips Hue, Nanoleaf and WLED
  • Flexible ssdp-Discovery incl. RegEx matching and filtering

Documentation

  • Process workflow for LED-Devices
  • Documentation of device classes & methods
  • Code template for new LED-Devices available

Changed

  • LED-Device workflow changed allowing proper suspend/resume & disable/enable scenarios
  • Network LED-Devices will stop sending packages when disabled
  • Rs232 Provider fully reworked and changed to synchronous writes
  • Rs232 configuration via portname and system location (/dev/ style), auto detection is not case-sensitive any longer
  • Additional error handling depending on device type
  • Add Windows compatibility incl. moving to Qt functions
  • Add compatibility for different Qt versions

Fixed

  • AtomOrb: Buffer length fix and new configuration validations
  • Added missing DMX SubTypes to configuration
  • Code clean-ups

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Docs
  • Build-related changes
  • Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

If yes, please describe the impact and migration path for existing setups:

The PR fulfills these requirements:

  • When resolving a specific issue, it's referenced in the PR's body (e.g. Fixes: #xxx[,#xxx], where "xxx" is the issue number)

If adding a new feature, the PR's description includes:

  • A convincing reason for adding this feature
  • Related documents have been updated (docs/docs/en)
  • Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

Resolves #755
Resolves #727
Resolves #859

Lord-Grey and others added 30 commits June 8, 2020 20:52
# Conflicts:
#	libsrc/leddevice/dev_net/LedDeviceNanoleaf.cpp
#	libsrc/leddevice/dev_net/LedDeviceNanoleaf.h
#	libsrc/leddevice/dev_spi/LedDeviceLpd8806.cpp
#	libsrc/leddevice/dev_spi/LedDeviceLpd8806.h
#	libsrc/leddevice/schemas/schema-nanoleaf.json
@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

@tihoangyeudau
Copy link

tihoangyeudau commented Jul 4, 2020

Wled and other udp devices works well but only udpe131 does not work anymore. please check it again

[hyperiond LEDDEVICE] <INFO> Start LedDevice 'udpe131'.
[hyperiond LEDDEVICE] <DEBUG> <LedDevice.cpp:127:LedDevice::init()> deviceConfig: [{"cid":"","colorOrder":"rgb","currentLedCount":105,"hardwareLedCount":105,"host":"192.168.0.144","latchTime":0,"port":5568,"type":"udpe131","universe":1}]
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdp.cpp:48:ProviderUdp::init()> Successfully parsed 192.168.0.144 as an ip address.
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdp.cpp:78:ProviderUdp::init()> UDP using 192.168.0.144:5568[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:36:ComponentRegister::setNewComponentState()> LED device: disabled

[hyperiond LEDDEVICE] <DEBUG> <LedDeviceUdpE131.cpp:57:LedDeviceUdpE131::init()> e131 no cid found, generated {0c73dd1d-fac9-4784-adeb-a5bb28fac110}

@Lord-Grey
Copy link
Collaborator Author

@tihoangyeudau Thanks for testing and confirming the WLED and other UDP Devices work well.
I found the problem on udpe131. When no CID is given and one is generated, I missed to set the device in the state that initialization was done successfully. If you configure a cid (using the one generated "0c73dd1d-fac9-4784-adeb-a5bb28fac110"), the device should work. I am going to fix it later....

@tihoangyeudau
Copy link

tihoangyeudau commented Jul 4, 2020

@tihoangyeudau Thanks for testing and confirming the WLED and other UDP Devices work well.
I found the problem on udpe131. When no CID is given and one is generated, I missed to set the device in the state that initialization was done successfully. If you configure a cid (using the one generated "0c73dd1d-fac9-4784-adeb-a5bb28fac110"), the device should work. I am going to fix it later....

yes, thank you for your try. your fork works very smoothly and fastly. Waiting for wled winzart and fixed udpe131

Copy link
Contributor

@m-seker m-seker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beware that I didn't check functionality as I am not familiar with the component, commented on the style only.

libsrc/leddevice/LedDeviceWrapper.cpp Outdated Show resolved Hide resolved
libsrc/leddevice/dev_hid/LedDeviceMultiLightpack.h Outdated Show resolved Hide resolved
libsrc/leddevice/dev_net/LedDeviceWled.cpp Outdated Show resolved Hide resolved
libsrc/leddevice/dev_net/LedDeviceYeelight.cpp Outdated Show resolved Hide resolved
libsrc/leddevice/dev_net/LedDeviceYeelight.cpp Outdated Show resolved Hide resolved
libsrc/leddevice/dev_net/LedDeviceYeelight.cpp Outdated Show resolved Hide resolved
libsrc/leddevice/dev_net/ProviderRestApi.cpp Outdated Show resolved Hide resolved
libsrc/leddevice/dev_net/ProviderRestApi.cpp Outdated Show resolved Hide resolved
@Lord-Grey
Copy link
Collaborator Author

Lord-Grey commented Jul 5, 2020

@tihoangyeudau Thanks for testing and confirming the WLED and other UDP Devices work well.
I found the problem on udpe131. When no CID is given and one is generated, I missed to set the device in the state that initialization was done successfully. If you configure a cid (using the one generated "0c73dd1d-fac9-4784-adeb-a5bb28fac110"), the device should work. I am going to fix it later....

yes, thank you for your try. your fork works very smoothly and fastly. Waiting for wled winzart and fixed udpe131

@tihoangyeudau Fix is available.

@tihoangyeudau
Copy link

Ok bro

@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

@Paulchen-Panther
Copy link
Member

Wolltest du hier noch aufräumen oder ist dieser PR fertig?

# Conflicts:
#	include/leddevice/LedDevice.h
#	libsrc/leddevice/LedDeviceTemplate.cpp
#	libsrc/leddevice/LedDeviceTemplate.h
#	libsrc/leddevice/dev_hid/LedDeviceMultiLightpack.cpp
#	libsrc/leddevice/dev_net/LedDeviceAtmoOrb.cpp
#	libsrc/leddevice/dev_net/LedDeviceNanoleaf.cpp
@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

This reverts commit 978ac75, reversing
changes made to aa346ed.
@hyperion-project
Copy link

Here is your new link to your workflow artifacts.

@Paulchen-Panther Paulchen-Panther merged commit 8eb5619 into hyperion-project:master Jul 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants